Plug-ins applications or external software programs perform significant roles in enhancing user experience with a host application. The plug-in applications or external software programs interact with the host application and provide additional features or more specialized solutions to the general functions available in the host application. For example, a plug-in application or an external software program to a browser application may enable the browser application display or render a particular type of file (e.g., a media file) or the like.
In using the plug-in application, the host application frequently uses a “invoking iteratively” calling convention in calling the plug-in application. Application following this convention will finish a bunch of homogeneous problems in a single calculate activity. The plug-ins will be invoked once for each of the problem.
For example, a financial analyzer may wish to recalculate a spreadsheet with 1500 rows. Each row represents a risk evaluation of a single portfolio unit. The risk evaluation will be performed by a third party plug-in's executable library. However, invoking this kind of third party function is likely to take a long time. In the above example, two to three seconds are needed for a personal computer (PC) to calculate a single risk evaluation which has 15000 Monte-Carlo simulations. That means the total time for calculating the 2000 rows would be about 4000 to 6000 seconds, which is more than one hour.
Currently, plug-ins are typically implemented as shared libraries that must be installed in a place prescribed by the main application. As such, in solving the problem described above, multi-threading is proposed as a solution to the problem. A computer with several CPUs or a CPU that has several cores can start a couple of threads to perform the simulations at the same time. However, the number of processors or cores of a processor of a computer could have is limited, and it is inefficient or unpractical to rely on a solution based on the number of processors alone.
The second approach involves redesigning the plug-in applications in a cluster-enabled or distributed computing environment as most of the applications are designed for only single thread execution. As such, current practices have required the developer to manually modify the plug-ins or/and the hosting application, then recompile/rebuild for the specific usage. The second type of practices involve requiring the user to change their behavior and operating style, such as to change user-defined functions (e.g., myfunction (a,b)) to different functions (e.g., cluster_run(“myfunction”, new object[2]{a,b})) that are able to take advantage of the processing powers of the cluster of the computing devices.
These two practices suffer from the source level modification limits since only the developer of hosting applications and plug-ins will have their source code. The user level modification is also unacceptable, since user has to reformat or reconfigured the user's codes and data to adapt to the cluster execution.